Method for isochronous resource management in a network based on hiperlan 2 techonology

ABSTRACT

The invention concerns a method for reserving isochronous resources on a wireless network of the Hiperlan 2 type for connection set-up, said network comprising an isochronous resource manager, said method comprising the steps of: identification of a talker de vice and a listener device by a connection controller, acquisition by the isochronous resource manager of the list of the devices to be part of the connection; determination of the bandwidth required for connecting the talker and the listener by the isochronous resource manager, as a function of the list of devices to be part of the connection; set-up of a multicast group including the talker device and the listener device if said bandwidth is available.

[0001] The invention concerns a network of wired buses, such as busesconforming to IEEE 1394 standard, in which at least some buses arelinked through wireless bridge connections forming a wireless network ofthe ETSI BRAN Hiperlan 2 type.

[0002] More specifically, the invention concerns a convergence layer forenabling devices to communicate over the wireless network.

[0003] The technical background regarding Hiperlan 2 and IEEE 1394 willfirst be described.

[0004] (1) Hiperlan 2 1394 Convergence Layer

[0005] A new generation of Wireless LAN called Hiperlan 2 is beingdefined by the ETSI BRAN project. The so-called Hiperlan 2 systems areintended to operate in the 5 GHz band, the user mobility beingrestricted to the local service area. The Hiperlan 2 (‘HL2’) networkstandardizes the radio access network and some of the convergence layerfunctions to different core networks. FIG. 1 represents the generalstack of Hiperlan 2.

[0006] In particular, the 1394 Convergence Layer (see references in thedetailed description section: document [3]) aims at describing a safemechanism to manage the isochronous connections in a wireless network.

[0007] The IEEE 1394 Convergence layer allows two kinds of devices tooperate over HL2, i.e. wireless bridge devices and wireless non bridgedevices.

[0008] (a) Wireless 1394 bridge devices. They contain bridge functionsto allow wired IEEE 1394 devices (controller, talker or listener) tocommunicate over the Hiperlan 2 network. They provide a wired IEEE 1394interface to allow the interconnection of IEEE 1394 serial buses overthe HL2 network.

[0009] (b) Wireless 1394 non bridge devices. These devices do notcontain any bridge function. They contain an IEEE 1394 application whichcan communicate with other IEEE 1394 applications over the Hiperlan 2network.

[0010] In conformance with the IEEE P1394.1 document (see document [6]below), the bridge model is defined as a set of two and only two portalsconnecting two serial buses.

[0011] The IEEE 1394 Convergence layer emulates the services of a serialbus, so that both non bridge devices and bridge devices can share a samefrequency.

[0012] Two 1394 applications should be able to operate directly over aHL2 network. The model also allows real wired bridge aware devices towirelessly communicate using wireless bridges.

[0013] FIG. 2 shows an example of a Hiperian 2 network as a virtual IEEE1394 bus. It comprises three wired 1394 busses (A, B and C), connectedto a wireless bus W through respective bridge devices AW, BW and CW. Awireless device D is connected directly to the wireless bus W withoutbeing connected to a wired bus.

[0014] In HL2, every isochronous channel is set up by a RLC (Radio LinkControl sublayer) multicast DLC (Data Link Control sublayer) Userconnection control procedure, involving the Central Controller. In HL2,there is a concept of link budget that depends on the radio receptionquality of the involved devices. HL2 defines several modulation schemesthat allow data exchange with a flexible robustness (the more robust themodulation scheme, the higher the required bandwidth). When one devicewants to send data to another device, it shall know the link budget todecide which modulation scheme it shall use, and thus how much of thenetwork resources it needs (in terms of HL2 time slots). In the DLC HomeExtension (see reference of document [2] below), a calibration mechanismis defined so that the Central Controller can gain knowledge of the linkbudget for any kind of connection.

[0015] (2) IEEE 1394-1995 Serial Bus and IEC 61883 for transport ofisochronous streams over a IEEE 1394 bus

[0016] The management of the Isochronous resources in a Serial Bus iscovered by the Isochronous Resource Manager (IRM) function described inthe IEEE1394-1995 standard. The IRM is not really in charge ofallocating bandwidth and channel but rather provides a single locationwhere other nodes may cooperatively record their usage of isochronousresource.

[0017] The IEC 61883 standard (see reference of document [5] below)specifies the transmission protocol for audiovisual data betweenequipment connected to an IEEE 1394-1995 Serial Bus. It also specifies aprotocol (Connection Management Procedure or ‘CMP’) so that nodes cancooperatively use the IRM to reserve bus resources. As specified by thisprotocol, when a Bus Reset occurs on a single serial bus, the followingactions are performed:

[0018] All AV devices that had connected input and output plugs priorthe bus reset shall continue respectively to receive and transmitisochronous data flow after the bus reset, during one second, accordingto values in the Plug Control Registers (cf. definition in [5]) whichexisted immediately before the bus reset.

[0019] Controllers that established connections before the bus resethave one second to reclaim resources. Unreclaimed resources are releasedby the IRM one second after the bus reset.

[0020] One second after the bus reset, all AV devices that had connectedinput and output plugs prior the bus reset are to behave according tothe values in the corresponding plug control registers (these values mayhave been updated by some controllers).

[0021] This procedure guarantees that a bus connection established by adevice (or application) is released if this device disappears andobviously if the source or the destination node disappears.

[0022] It means that after a bus reset, the isochronous streams arereestablished according to the presence or not of the devices involvedin the connection.

[0023] Since the 1394 convergence layer aims at emulating a virtualserial bus, it is to provide a similar mechanism for the management ofthe isochronous connections in a Hiperlan 2 network. This mechanismshall provide the same kind of functions as those existing on a realserial bus. It shall also be easily mapable on the existing HL2 lowerlayer protocols (DLC/RLC).

[0024] The description below describes such a mechanism.

[0025] The invention as claimed concerns a method for reservingisochronous resources on a wireless network of the Hiperlan 2 type forconnection set-up, said network comprising an isochronous resourcemanager, said method comprising the steps of:

[0026] identification of a talker device and a listener device by aconnection controller;

[0027] acquisition by the isochronous resource manager of the list ofthe devices to be part of the connection

[0028] determination of the bandwidth required for connecting the talkerand the listener by the isochronous resource manager, as a function ofthe list of devices to be part of the connection;

[0029] set-up of a multicast group including the talker device and thelistener device if said bandwidth is available.

[0030] According to an embodiment of the invention, the step ofacquiring the list of devices to be part of the connection by theisochronous resource manager comprises the steps:

[0031] request of a channel identifier by the connection controller fromthe isochronous resource manager,

[0032] transmission by the connection controller of the channelidentifier to the talker device and the listener device,

[0033] having each device carry out a radio link control layer groupjoin procedure with the central controller of the network, based on thechannel number,

[0034] having the central controller attribute a multicast medium accesscontrol identifier to said group.

[0035] According to an embodiment of the invention, the method furthercomprises the steps of, after a reset of the wireless network,

[0036] providing a first time interval (T) during which controllers arerequired to reclaim isochronous resources reserved before the reset, and

[0037] providing a second time interval (ΔT) following the firstinterval and during which a controller may not make new reservationswith the isochronous resource manager.

[0038] According to an embodiment of the invention, the second timeinterval is set to allow all devices of the network to finish theirreset procedure after a network reset triggered by the centralcontroller.

[0039] According to an embodiment of the invention, connectioncontrollers comprise a register for storing the second time interval,this register being programmable by the central controller.

[0040] According to an embodiment of the invention, the method furthercomprises the steps of:

[0041] providing a bus generation register in each node,

[0042] having the central controller update the content of the busgeneration register of a node during a network reset, the new registercontent being sent in a network reset message to the node,

[0043] having the isochronous resource manager test for the latest valueof the bus generation register content in a resource request from a nodeand reject the request if the bus generation register content of thenode is not correct.

[0044] It is to be noted that the notions of the additional safeguardperiod delta T and the bus generation number are inventions in their ownright and might be claimed separately.

[0045] Other characteristics and advantages of the invention will appearthrough the description of a particular embodiment, described inrelation with the figures, among which:

[0046]FIG. 1, already described, represents the general stack ofHiperlan 2,

[0047]FIG. 2, already described, shows an example of a Hiperlan 2network as a virtual IEEE 1394 bus,

[0048]FIG. 3 represents an example of a hybrid network and itsmodelization as a network comprising a virtual bus,

[0049]FIG. 4 represents the format of the ‘Virtual_Channel_Available’register according to the embodiment of the invention,

[0050]FIG. 5 represents the format of the ‘Virtual_Channel_Available’register,

[0051]FIG. 6 represents the format of the Virtual input Plug ControlRegister (ViPCR),

[0052]FIG. 7 represents the format of the Virtual output Plug ControlRegister (VoPCR),

[0053]FIG. 8 represents relative T and ΔT periods (resp. representingthe delay for reclaiming isochronous resources after a reset and thedelay during which new reservations are forbidden following the end ofthe first delay) for the Hiperlan 2 Central Controller and the mobileterminals MT1 and MT2 of FIG. 3,

[0054]FIG. 9 is a diagram illustrating the messages exchanged betweenthe Central Controller and the different mobile terminals of FIG. 3 fora non-overlaid connection,

[0055]FIG. 10 is a diagram of a network for an overlaid isochronousconnection, in which a mobile terminal MT4 is to be overlaid onto anexisting connection,

[0056]FIG. 11 represents the messages exchanged between the CentralController and the mobile terminals in this case,

[0057]FIG. 12 is an example of a network architecture in a bridgeenvironment,

[0058]FIG. 13 is a diagram representing the modelization of a virtualbus.

[0059] The present embodiment concerns a network of IEEE 1394 wiredbuses, interconnected by wireless bridges based on Hiperlan 2.Nevertheless, it is clear to the Man Skilled in the Art that theprinciples described in the present document may also apply to otherenvironments and that the invention is thus not limited to the specificenvironment described herein. Detailed information concerning BRANHiperlan 2 and IEEE 1394 bus standard and related specifications can befound among others in the following documents:

[0060] [1] ETSI BRAN Hiperlan2 Technical Specification, Data LinkControl Layer, Part 1: Basic Data Transport Function.

[0061] [2] ETSI BRAN Hiperlan2 Functional Specification, Data LinkControl Layer, Part 4: Extension for Home Environment.

[0062] [3] ETSI BRAN Hiperlan2 Technical Specification, Packet BasedConvergence Layer, Part 3: IEEE1394 Service Specific ConvergenceSublayer (draft), version 0.0.0. (1999-12).

[0063] These three documents, as well as other documents relating toHiperlan 2, are available from the European Telecommunications StandardsInstitute.

[0064] [4] IEEE1394-1995 Std, IEEE Standard for a High PerformanceSerial Bus.

[0065] [5] IEC611883, Digital Interface for consumer Audio/VideoInterface.

[0066] [6] IEEE1394.1 Draft Standard for High Performance Serial BusBridges (Feb. 7, 1999)

[0067] The two documents [4] and [6] are available from the IEEEorganization, while the document [5] is available from the IEC.

[0068] According to the present embodiment, an isochronous resourcemanager (IRM) function is defined on the virtual bus of FIG. 1. Theisochronous resource reservation mechanism according to the presentembodiment provides functions to:

[0069] Reserve isochronous resources (channels and bandwidth)

[0070] Release these resources when either the controller, talker orlistener leaves the HL2 network.

[0071] According to the present embodiment, the isochronous resourcereservation mechanism is located in the Convergence layer. This allowsboth an application and a bridge layer to use these functions.

[0072] In the present embodiment, the IRM function is located on theHiperlan 2 (HL2) Central Controller's 1394 Convergence layer. Itprovides a “channel available register” and “bandwidth availableregisters”, so that other device applications can make resourcereservations, using the appropriate lock requests (“lock_req/res”). As adifference to the IEEE 1394-1995 IRM, these registers are slightlycoupled together, so that when a reservation comes for a certain amountof bandwidth, the IRM knows for which channel it is. This allows theCentral Controller to compute the link budget for that channel (it knowsthe devices that are member of the group MAC-ID—MAC standing for MediumAccess Control). If there are sufficient network resources, the IRM willgenerate a favorable lock_res message, otherwise it will generate arejecting lock_res message.

[0073] At every HL2 network change (a device has been associated orde-associated) (i.e at each virtual bus reset), network resources needto be reclaimed from the IRM within one second. Else, these resourcesare released. In HL2, a bus reset takes some time to be propagated.According to the present embodiment, a ‘bus generation number’ is usedin the IRM registers, so that the IRM can distinguish between a new andold resource claim and react accordingly. Bus generation number bits arespecific to the HL2 IRM, and are not defined for a standard IEEE1394-1995 bus IRM.

[0074] 1. Introduction

[0075] The invention proposes adapting the management of isochronousconnections of the IEEE1394-1995 bus for a HL2 network. In what follows,the term “virtual” will be used to describe the vocabulary attached tothe virtual bus.

[0076] Since the data rate is lower on a wireless medium than on a realserial bus, the number of virtual channels can be limited, as anexample, to 32. Of course, other values may be used.

[0077] The left part of FIG. 3 is a diagram of a wireless bus to whichfour devices are connected: A Central Controller (CC) and three mobileterminals MT1, MT2 and MT3, respectively acting as talking device,listening device and 1394 Controller. The right part of FIG. 3represents the modelization of the wireless network as a virtual bus, towhich the four devices are connected.

[0078] IEEE 1394 isochronous channels are mapped to multicast groupMedium Access Control Identifiers (‘MAC-IDs’). In the Data Link ControlLayer Home Extension (‘DLC HE’), there is a current limitation of themulticast channel number (the maximum number channels being 32).

[0079] According to the present embodiment, VIRM (Virtual IRM) registersare defined: V_BANDWIDTH_AVAILABLE and V_CHANNEL_AVAILABLE. Theseregisters are present in the 1394 Convergence Layer of the CentralController.

[0080] The following registers are also defined: ViPCR (Virtual inputPlug Control registers) and VoPCR (Virtual output Plug ControlRegisters), for those wireless devices that can source or sinkisochronous streams.

[0081] In a Hiperlan2 environment, resource management (multicast groupsand network bandwidth) is done by the Central Controller.

[0082] The virtual isochronous resource manager (VIRM) may run in theConvergence Layer of any node: as on a serial bus, the IRM function maybe implemented on any IRM capable node. The only requirement is thatthere shall be only one IRM running at a time, and that every node shallknow where it is. According to the present embodiment, forsimplification reasons, IRM has been located in the cycle master on aserial bus.

[0083] Also in order to simplify the protocols (nodes know where itruns, less constraints between bus_reset propagation and resourcereclaim), it is proposed that the IRM runs in the Central Controller'sConvergence Layer. The virtual IRM has to drive the RLC multicastconnection control procedure for the HL2 network.

[0084] To comply with the IEC61883 standard (document [5]) as much aspossible, it is proposed that the connection be established by an IEEE1394 controller. A 1394 controller is a 1394 node running an applicationthat aims at controlling other devices such as talkers and listeners.The concept of 1394 controller is defined and used in the IEC61883standard (document [5]). This application will reserve bandwidth andchannel in the VIRM and configure the virtual input and output controlplug registers (‘ViPCR’ of the listener and ‘VoPCR’ of the talker)according to the following rules.

[0085] 2. Control and Status Registers Description

[0086] 2.1. Isochronous Resource Manager (VIRM) Registers

[0087] According to the present embodiment, VIRM registers implementedin the 1394 CL of the Central Controller. Format as well as accessingrules are defined as follows according to the present embodiment:

[0088] 2.1.1. VIRTUAL_CHANNEL_AVAILABLE Register

[0089] This register is implemented on the Virtual Isochronous ResourceManager (VIRM). It is two quadlets long (to be compared to theCHANNEL_AVAILABLE register of a wired serial bus IRM). Only the2-quadlet Read and Lock compare swap transaction shall be supported inorder to avoid that several applications reserve the same channel. Thebits 0 to 31 of this register correspond to the isochronous channels 0to 31 of the virtual bus. As for a serial bus IRM, a bit value of 0indicates the corresponding channel is reserved and thereforeunavailable for further reservation. According to the presentembodiment, specific to the VIRM, some bits are used for the busgeneration number (i.e. bits 32 to 36). Other bits are reserved.

[0090] Read and Lock compare swap transactions on this register are usedby the reserving controller either to reserve a new channel or toreclaim an already reserved channel after a virtual bus reset.

[0091]FIG. 4 represents the format of the ‘Virtual_Channel_Available’register.

[0092] Accessing Rules:

[0093] Virtual bus reset operation

[0094] After a virtual bus reset (self_id packet received from theCentral Controller, carrying a bus generation number), the register bitsrepresenting the available channels are cleared. All channels becomeavailable again. The ‘Gen_Number’ bits are updated as well (according toinformation present in the self_id packets sent after the bus reset andreceived by the node implementing the VIRM). A timer T is started.Before the timer expires, resources (channels) have to be reclaimed. Inorder to decide whether to accept a resource reclaim, the VIRM comparesthe Gen_Number bits with the corresponding bits in the Lock request. Ifthey match, the VIRM knows that the request was made by a device presenton the virtual bus before the reset and the resource reclaim request isaccepted. If on the other hand, they do not match, the resource reclaimrequest is rejected. When the timer T expires, resources which have notbeen reclaimed are released (Group Mac_Ids are released in theConvergence Layer).

[0095] Standard Operation, corresponding to the period between virtualbus reset timer T expiry and next virtual bus reset:

[0096] The VIRM shall behave as any serial bus IRM. It shall reject alock request on an already reserved channel. When a channel is reserved(via a Lock request message) the IRM is ready to receive RLC_GROUP_JOINmessages on this channel. When the first RLC_GROUP_JOIN message isreceived for that channel, the Central Controller shall create a newgroup MAC-ID. Next RLC_GROUP_JOIN messages for the same channel will addMobile Terminals to the same group MAC-ID.

[0097] 2.1.2. VIRTUAL_BANDWIDTH_AVAILABLE Register

[0098] This register is also implemented on the VIRM. It allows acontroller to reserve bandwidth for a particular channel. It is onequadlet long. Bits 27 to 31 are dedicated to the bus generation number.The other bits (0 to 26) are dedicated to express the bandwidthavailable on the virtual bus as a number of bits or bytes per second atthe Convergence Layer level. For the bandwidth bits, some reservedvalues are not allowed (for example the value 0×FFFF is reserved).

[0099] A Read Request to this register allows a device to get theBandwidth available in HL2 network.

[0100] The reservation of bandwidth is made through a Lock Requestmessage where the arg_value is composed of two quadlets:

[0101] The first quadlet indicates the selected channel. In this word,the only bit set to 1 indicates the selected channel. The Isbcorresponds to channel 0 and the msb to channel 31;

[0102] The second quadlet is composed of the result of a previous readto this register for the bits 0 to 25 and the generation number of thecontroller for the bits 26 to 31.

[0103] The data value is a quadlet indicating the bit rate requested forthe particular channel.

[0104] The request will be rejected if:

[0105] the channel indicated in the arg_value is not available in theCHANNEL_AVAILABLE register; or

[0106] the Generation number indicated in the Lock request is differentfrom the generation number of the IRM; or

[0107] the quantity of bandwidth indicated in the Lock Request is higherthan the available bandwidth (another node reserved bandwidth since thereading by the controller).

[0108] Accessing Rules:

[0109] Standard Operation (period between virtual bus reset timer Texpiry and next virtual bus reset):

[0110] When the IRM gets a lock request on theVIRTUAL_BANDWIDTH_AVAILABLE register, it knows the requested bandwidthas well as the channel it is for. It shall then compute the topology map(that it built from the calibration, described in clause 6.5 of document[2]) in relation to the multicast group MAC-ID (as a result of the RadioLink Control (‘RLC’) multicast join procedure, the Convergence Layerknows the list of Mobile Terminals for a particular 1394 channel. It canthus determine the relevant modulation scheme for this multicast group,depending of the link quality, and thus check whether there are enoughavailable resources (HL2 time slots). If there are enough availableresources, it will accept the reservation, and start a RLC multicastconnection setup procedure within the multicast group. If the RLCprocedure succeeds, then a favorable lock response message will begenerated as an answer to the lock request message. If the reservationfails (because of a lack of link budget, or because the RLC fails), thenthe lock request will be rejected by a lock response message. In theargument (old_value) of the rejecting lock response message, acorresponding error code will be inserted (for example one of theforbidden values of the bandwidth available bits), so that the requesteris informed of the reason of the rejection.

[0111] As for a serial bus IRM, the lock request is rejected if thebandwidth previously read during a read transaction and inserted intothe lock request message as an argument does not correspond to thecurrent bandwidth available (two concurrent reservation procedurescollide).

[0112] Virtual bus reset operation

[0113] After a virtual bus_reset (self_id packet received from theCentral Controller, carrying a generation bus number),Bandwidth_available bits are reset (all bandwidth becomes availableagain). Gen_Number bits are updated as well, according to informationpresent in the self_id packets received by the VIRM. A timer T isstarted. Before the timer expires, resources (bandwidth) have to bereclaimed. In order to accept a resource reclaim, the VIRM uses theGen_Number bits (if they match, resource reclaim is accepted, if they donot match, resource reclaim is rejected). When the timer T expires, thenun-reclaimed resources are released (any existing multicast connectionwithin the multicast group is released using the RLC).

[0114]FIG. 5 gives the format of the ‘Virtual_Channel_Available’register.

[0115] 2.1.3 ViPCR and VoPCR Virtual Input and Output Plug ControlRegisters

[0116] The ViPCR register (or set of registers) is implemented in a 1394Convergence Layer of a device that can sink isochronous streams. It hasthe same functionality as the iPCR defined in [5]. This register isimplemented according to the Command and Status Register (CSR)architecture. A generation field is added to take into account thedifference of time in the Virtual Bus Reset Notification. The generationnumber is incremented modulo 2⁵ at each Virtual Bus Reset.

[0117]FIG. 6 represents the format of the ViPCR register.

[0118] The VoPCR register (or set of registers) is implemented in the1394 Convergence Layer of a device that can source isochronous streams.It has the same functionality as the oPCR defined in [5]. This registeris implemented according to the CSR architecture. A generation field isadded to take into account the difference of time in the Virtual BusReset Notification (cf. [3]). The bus generation number is incrementedmodulo 2⁵ at each Virtual Bus Reset.

[0119]FIG. 7 represents the format of the VoPCR register.

[0120] The Payload, the Overhead ID, Point to point connection counterand the On-Line fields have the same definition as the equivalent fieldsof the oPCR defined in [5].

[0121] While it is coded on 6 bits in order to be coherent with document[5], the channel will be in the range of 0 to 31.

[0122] The generation number indicates the generation of the lastVirtual Bus Reset received by the node. It is set by the node itself byusing an incremental counter at each virtual bus reset or by using acounter associated with the virtual bus reset notification and managedby the Central Controller. This field is necessary because all theWireless Terminals are not informed of a virtual bus reset at the sametime.

[0123] Accessing rules for the Vo and Vi PCR registers:

[0124] Standard Operation (period between a virtual bus reset timer Texpiry and the next virtual bus reset):

[0125] When a Convergence Layer of a node receives a lock request on aPCR (either input or output) and with the channel bits set, then a RLCjoin request procedure shall be started to the Central Controller. Oncethe RLC join response message is positively received, then a successfullock response message is generated. Otherwise, the lock request isrejected.

[0126] Bus reset operation: when the Convergence Layer implementing thePCR is informed of a bus reset, it sets the Gen_bus_number bits of itsPCR(s) to the new value. The Convergence Layer starts a timer for theinterval T, and operates sink or source data as it did before the busreset. It also clear the channel bits of the PCRs. If channel bits arewritten again before the T timeout, nothing changes. Otherwise, theConvergence Layer will generate an RLC_Leave procedure towards theCentral Controller to leave the multicast group.

[0127] Accessing rules (seen from the point of view of the controllerapplication):

[0128] The application first reserves a channel with the IRM (by readingthe VIRTUAL_CHANNEL_AVAILABLE register, followed by a lock request),then writes the reserved channel into the ViPCRs and VoPCR of the nodesof the multicast group it wants to establish. Once all the lock responsemessages have been obtained, it reserves the relevant bandwidth bysending a lock request message to the VIRTUAL_BANDWIDTH_AVAILABLEregister. Then the VIRM can safely compute the link budget for thatmulticast group.

[0129] When a virtual bus reset occurs, the application has to reclaimresources from the IRM registers and the relevant Vo or ViPCRs withinthe one second interval. It then stops sending any new reservationrequests for a period ΔT, as described below.

[0130] 2.2 Virtual Bus Reset and Resource Reclaim or Release Virtual BusReset Operation

[0131] When the HL2 Radio Link Control layer of a Central Controllerdetects that either a device has left the network, or that a new devicehas been associated (following a RLC association procedure), theidentification (‘self_id’) procedure at the 1394 Convergence Layer levelensures that the Central Controller sends a virtual bus reset message toall other device Convergence Layers. Each 1394 Convergence Layer canthus generate a virtual bus reset to its upper layer triggered by thereception of the virtual bus reset message, with a certain propagationdelay.

[0132] Each device contains memory dedicated to storing a virtual busreset number which is the already mentioned generation number. The busgeneration number is increased by the Central Controller at each busreset. The bus reset generation number is contained in the self_idmessages.

[0133] When a controller receives a bus reset indication, it has tore-allocate all its connections within one second. After this time, itis not allowed to send either reclaim or normal claim messages during aperiod ΔT. But a device can receive and accept a request during thisperiod ΔT (see FIG. 8).

[0134] This time interval ΔT shall be longer than the difference of timebetween the bus reset event on the Central Controller and the bus resetevent on the last Mobile Terminal receiving the reset. That principleguarantees that a Mobile Terminal will never try to reclaim a resourceafter the end of the bus reset on a device.

[0135] As for the split timeout register, it is proposed thatConvergence Layers contain a ΔT Control and Status Register (‘CSR’), sothat a Central Controller can adjust this value if it becomes overloadedin Mobile Terminals (if the number of MT increases by an importantfactor, the bus reset may take more time than the ΔT period, so that theresource reservation may sometimes fail (i.e. generate another busreset). Thus in some cases it may be advantageous to increase thisvalue). ΔT CSR (as for the split timeout of 1394) will have a defaultvalue.

[0136] If for some reason, the bus reset requires a longer time than ΔTto be propagated in a HL2 network, then the Central Controller has toincrease the bus reset generation number and start another a bus reset.

[0137]FIG. 8 represents the relative T and ΔT periods for the CentralController and the mobile terminals MT1 and MT2 of FIG. 3.

[0138] When the 1394 Convergence Layer of the Central Controller startsa bus reset sequence, then it has to free all the bandwidth and channelswithin the virtual IRM. At the same time, when devices receive thevirtual bus reset, ViPCR and VoPCR will have to be released and a timerT=(1s+ΔT) initialized.

[0139] Several cases may occur after a virtual bus reset:

[0140] No Device Gone

[0141] The controller that allocated resources prior the bus reset andthat receives a bus reset has to check whether both the talker and thelistener are still on the network. If they are, then the controller hasto reallocate resources in the VIRM. The VIRM uses the bus generationnumber bits to detect that the lock request is a reclaim and not a newclaim (that could have been generated by a device before it actuallyreceived the bus reset). The controller will also have to reconfigurethe ViPCR of the listeners and the VoPCR of the talker.

[0142] In this case, the HL2 connections are not released and cancontinue to operate.

[0143] 1394 Controller is Gone

[0144] The IEC61883 document specifies that if the controller isdisconnected, then a connection established by this controller is to bebroken. According to the present embodiment, the virtual IRM will waitduring the time interval T for the reclaiming. When the time runs outwithout a reclaim being received, the Central Controller sendsRLC_RELEASE messages to the talker and each listener. The talker and thelisteners will leave the multicast group. As no devices will remain inthe multicast group, the CC will free the reserved resources in theregisters. In a similar way, the talker and the listener of thisconnection (i.e. the connection that was established by a controllerthat has been removed from the bus) will detect that no resource reclaimhas been made in their PCR, will have to leave the multicast group bysending a RLC_LEAVE to the CC.

[0145] Talker or Listeners Gone

[0146] A connection should be broken if either the talker is missing orall listeners left the network. The 1394 controller will try to find thetalker and listeners, and if this condition is not respected then itwill not reallocate necessary resources.

[0147] Each device will manage the time out and will have to release theHL2 connections.

[0148] 2.3 Non Bus Reset Resource Release

[0149] As on a serial bus, an application (or bridge layer) may decideat any time to release some resources on the virtual bus. This shall bedone in a fashion similar to that of the reservations (writing into thePCRs and IRM registers to release some bandwidth for a particularchannel, and then release some channels).

[0150] 2.4 Scenarios

[0151] 2.4.1. Isochronous Connection Between Wireless Devices.

[0152] 2.4.1.1. Non Overlaid Connection.

[0153] (1) The 1394 controller performs a compare and swap transactionto the Virtual Isochronous Resource Manager located in the CentralController in order to allocate the channel. This is an IEEE1394-1995transaction.

[0154] (2) The controller sends a lock_req message to the talker and thelisteners at the ViPCR and VoPCR (with online bit set to off) addressesto set the channel of the previous step. If its generation number isdifferent from the controlled device, the controller is not able toestablish a connection, resulting in a rejecting lock_res messagegenerated with an appropriate <<error code>>.

[0155] (3) Both the talker and the listeners perform the Join RLCprocedure on this channel. After the Join is completed, both the talkerand the listeners generate the favorable lock_resp to the controller.

[0156] (4) When the controller gets the lock_resp, the CentralController knows which devices are members of the multicast group. Thecontroller can then send a lock_req on the BANDWIDTH_AVAILABLE register(according to the procedure described in above).

[0157] (5) The IRM calculates the required HL2 bandwidth (depending onthe link budget, and the selected physical layer (PHY) mode).

[0158] (6) Two cases are possible:

[0159] (a) Bandwidth is available, then go to (7) the IRM sends apositive lock response and then immediately after (before accepting anew lock_req) updates the bandwidth register (taking the PHY mode intoaccount)

[0160] (b) Bandwidth is not available: the IRM sends a negative lockresponse (with the appropriate error code in the arg_value). Thebandwidth register remains unchanged—The controller knows (via the errorcode) that it shall not loop in asking.

[0161] (7) If bandwidth was available, the Central Controller starts amulticast DLC User Connection (DUC) setup into the multicast group. IfRLC succeeds, then a positive lock response is generated (the bandwidthavailable register is updated taking the PHY mode into account), else anegative one is generated.

[0162] (8) Generally, no other lock request is accepted until thecorresponding lock response is generated.

[0163]FIG. 9 is a diagram illustrating the messages between the CentralController and the different mobile terminals of FIG. 3 for anon-overlaid connection.

[0164] 2.4.1.2. Overlaid Connections.

[0165] An overlaid connection is defined in the IEC 61883 specification.Overlaying a connection consists in adding listeners to an alreadyexisting connection. In that case, there already are a HL2 multicastconnection and IRM CSR in the 1394 convergence layer.

[0166]FIG. 10 is a diagram of a network for an overlaid isochronousconnection, in which a mobile terminal MT4 is to be overlaid onto anexisting connection.

[0167] The following steps describe how the device MT4 becomes a newlistener:

[0168] (1) The controller sets the VoPCR of the talker to increment thepoint to point connection counter. It also loads the ViPCR of the newlistener with the channel by sending a lock_req and checking generationnumber.

[0169] (2) MT4 can now send a RLC_GROUP_JOIN message to the CentralController for the corresponding channel.

[0170] (3) If the Link Budget allows to add MT4 to join the groupmulticast, the Central Controller sends back the acknowledgement withthe associated multicast MAC_ID.

[0171] (4) Both listeners and talker can send the lock_resp to thecontroller.

[0172] (5) The Central Controller shall send a multicast DUC setupprocedure to the MT4 device. The device MT4 is then ready to receivedata. Possibly, if the PHY mode needs to be changed, a RLC modifyprocedure may even be started

[0173]FIG. 11 represents the messages exchanged between the CentralController and the mobile terminals in this case.

[0174] 2.4.2. Isochronous Connection Setup in a Bridge Environment

[0175] The following part describes how the isochronous reservationmechanisms, as defined in the 1394 Convergence Layer, may be used in abridge environment.

[0176] The network is composed of four serial buses numbered from 1 to 4connected to the Hiperlan 2 network through the portals MT1 to MT4 (cf.FIG. 12).

[0177]FIG. 12 is an example of a network architecture in a bridgeenvironment.

[0178] The wireless network can be modelized as a virtual 1394 bus (cf.FIG. 13). Each portal is represented as bridge connected to the VirtualBus. Such a bridge is made of:

[0179] a portal connected to the wired serial bus: this is the realportal

[0180] a portal connected to the virtual bus: this is a virtual portalwhich uses the services of the 1394 Convergence Layer (i.e. Virtual iPCRand oPCR registers). The IRM of the virtual bus is noted VIRM and isimplemented in the 1394 Convergence Layer of the Central Controller.Moreover, the device which is in charge of establishing an isochronousconnection on the virtual bus is called Virtual Controller.

[0181]FIG. 13 is a diagram representing the modelization of a virtualbus.

[0182] 2.4.2.1. Non Overlaid Connections

[0183] The different steps are as follows:

[0184] (1) The controller sends a Connect Message to the Listener'sPortal. The virtual portal of this device becomes the Virtual Controllerfor the establishment of the connection on the virtual bus.

[0185] (2) The virtual Controller reserved resources on the virtual busas described in the previous sections.

[0186] (3) If resources are available on the virtual bus, the Listenerportal (LP) sends a bridge connect message to the talker portal, . . .as described in P1394.1 drafts.

[0187] 2.4.2.2 Overlaid Connection

[0188] The controller sends a Connect Message to the Listener's Portal.This connect message shall contain the information that this is anoverlaid connection by indicating the existing channel number in use.

[0189] The Listening Portal sets the allocated channel bit of its ViPCRand set the VoPCR of the talker's portal by sending a lock_req message.The talker's portal shall increase the point_to_point_connection_counterin its VoPCR.

[0190] On the virtual bus everything happens then as for an overlaidconnection.

[0191] Acronyms and Abbreviations.

[0192] Bridge: a set of two serial bus nodes capable of connecting twobuses in a serial bus net.

[0193] Central Controller (CC): Provides control functionality for theDLC layer (Data Link Control layer) equivalent to that of an accesspoint as defined by Hiperlan 2, but is not necessarily attached to afixed network. The central controller functionality may be embedded in awireless device.

[0194] Controller: the device that establishes an isochronous connectionon a Serial Bus.

[0195] Portal: a node that connects a bridge to a Serial Bus.

[0196] Virtual Bus: it is the model of the wireless network as a 1394Serial Bus.

1. Method for reserving isochronous resources on a wireless network ofthe Hiperlan 2 type for connection set-up, said network comprising anisochronous resource manager, said method comprising the steps of:identification of a talker device and a listener device by a connectioncontroller; acquisition by the isochronous resource manager of the listof the devices to be part of the connection; determination of thebandwidth required for connecting the talker and the listener by theisochronous resource manager, as a function of the list of devices to bepart of the connection; set-up of a multicast group including the talkerdevice and the listener device if said bandwidth is available.
 2. Methodaccording to claim 1, wherein the step of acquiring the list of devicesto be part of the connection by the isochronous resource managercomprises the steps: request of a channel identifier by the connectioncontroller from the isochronous resource manager; transmission by theconnection controller of the channel identifier to the talker device andthe listener device; having each device carry out a radio link controllayer group join procedure with the central controller of the network,based on the channel number; having the central controller attribute amulticast medium access control identifier to said group.
 3. Methodaccording to one of the claims 1 and 2, comprising the steps of, after areset of the wireless network, providing a first time interval (T)during which controllers are required to reclaim isochronous resourcesreserved before the reset, and providing a second time interval (ΔT)following the first interval and during which a connection controllermay not make new reservations with the isochronous resource manager. 4.Method according to claim 3, wherein the second time interval is set toallow all devices of the network to finish their reset procedure after anetwork reset triggered by the central controller.
 5. Method accordingto one of the claims 3 or 4, wherein connection controllers comprise aregister for storing the second time interval, this register beingprogrammable by the central controller of the network.
 6. Methodaccording to one of the claims 3 to 5, wherein during the second timeinterval, a connection controller may not make any reclaim of resourcesreserved before the reset procedure.
 7. Method according to one of theclaims 1 to 6, wherein the isochronous resource manager is implementedin the central controller.
 8. Method according to one of the claims 1 to7, further comprising the steps of: providing a bus generation registerin each node, having the central controller update the content of thebus generation register of a node during a network reset, the newregister content being sent in a network reset message to the node,having the isochronous resource manager test for the latest value of thebus generation register content in a resource request from a node andreject the request if the bus generation register content of the node isnot correct.